home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1993
/
Internet Info CD-ROM (Walnut Creek) (1993).iso
/
inet
/
internet-drafts
/
draft-newnan-isomib-internet-00.txt
< prev
next >
Wrap
Text File
|
1993-03-03
|
124KB
|
2,915 lines
INTERNET DRAFT Expires April 23, 1993
ISO/CCITT and Internet Management Coexistence (IIMC):
Translation of ISO/CCITT GDMO MIBs to Internet MIBs
(IIMCOMIBTRANS)
October 9, 1992
Owen Newnan
U S WEST Advanced Technologies
4001 Discovery Lane
Suite 190
Boulder, Colorado 80303
onewnan@uswest.com
303 541-6253 fax x6250
Status of this Memo
This memo provides information to the network and systems
management community. This memo is not proposed to be a
standard, but is intended as a contribution to ongoing work
in the area of multi-protocol management coexistence and
interworking. This memo is part of a package of ISO/CCITT
and Internet Management Coexistence (IIMC) drafts; see also
[IIMCIMIBTRANS], [IIMCMIB-II], [IIMCPARTY], and [IIMCPROXY].
This document is an Internet Draft. Internet Drafts
are working documents of the Internet Engineering Task
Force (IETF), its Areas, and its Working Groups. Note
that other groups may also distribute working documents
as Internet Drafts.
Internet Drafts are draft documents valid for a maximum
of six months. Internet Drafts may be updated,
replaced, or obsoleted by other documents at any time.
It is not appropriate to use Internet Drafts as
reference material or to cite them other than as a
"working draft" or "work in progress".
Please check the 1id-abstracts.txt listing contained in
the internet-drafts Shadow Directories on nic.ddn.mil,
nnsc.nsf.net, nic.nordu.net, ftp.nisc.sri.com,
munnari.oz.au to learn the current status of any
Internet Draft.
Draft ISO/CCITT GDMO MIBs to Internet MIBs 10/9/1992
Distribution of this memo is unlimited. Comments on this
memo should be sent to iimc@thumper.bellcore.com by November
20, 1992.
Abstract
This memo is intended to facilitate the use of ISO/CCITT CMI
for integrated management of networks via proxy management
of TCP/IP networks that are managed using SNMP. This memo
provides heuristic procedures that translate managed object
specifications from ISO/CCITT Guidelines for Definition of
Managed Object (GDMO) templates to Internet MIB macros.
Currently, some market segments demand SNMP for customer
network management while others require the ISO/CCITT Common
Management Information Protocol (CMIP). This approach
accommodates both, protecting investment already made in
management information specifications and minimizing cost to
implement a second protocol where the market requires. The
translation is designed to: lose as little functionality as
possible in translation; minimize need for human involvement
to translate; minimize cost to implement dual protocol and
proxy-based applications; and support generic network models
that span many computer platforms and network elements. It
has been contributed the network and systems management
community to encourage standardization of such an approach
and promote consistent usage of MIB definitions independent
of protocol.
Table of Contents
Status of this Memo ......................................i
Abstract .................................................ii
Table of Contents ........................................ii
1. Introduction ..........................................4
1.1 Background ...........................................4
1.2 Overview .............................................5
1.3 Scope ................................................8
1.4 Terms and Conventions ................................8
2. Translation Procedures ................................9
2.1 Relationship to RFC 1212 .............................9
2.2 Mapping of Managed Object Classes and Attributes .....10
2.3 Mapping to the SYNTAX clause .........................16
2.4 Generation of Internet MIB Identifiers ...............19
2.5 Mapping to the ACCESS clause .........................22
2.6 Mapping to the STATUS clause .........................22
2.7 Mapping to the DESCRIPTION clause ....................22
2.8 Mapping to the REFERENCE clause ......................23
2.9 Mapping to the INDEX clause ..........................23
2.10 Mapping to the DEFVAL clause ........................23
2.11 Translation of Actions ..............................23
2.12 Translation of Notifications ........................24
2.14 Translation of Create Operations ....................25
Newnan Page ii
Draft ISO/CCITT GDMO MIBs to Internet MIBs 10/9/1992
3 Constraints on SNMP Usage ..............................26
3.1 Approach .............................................26
3.2 Discussion ...........................................27
4 Summary ................................................28
5 Acknowledgments ........................................28
Appendix A: Abridged Example .............................32
A.1 Input: ISO/CCITT Management Information Base .........32
A.2 Output: Internet MIB Macros ..........................36
Appendix B: Abridged ISO/CCITT Compatibility MIB .........42
References ...............................................47
Newnan Page iii
Draft ISO/CCITT GDMO MIBs to Internet MIBs 10/9/1992
1. Introduction
1.1 Background
This memo is part of a package of ISO/CCITT and Internet
Management Coexistence (IIMC) drafts. Other memos included
in this package are:
o Translation of Internet MIBs to ISO/CCITT GDMO MIBs
(LaBarre) [IIMCIMIBTRANS]
o Translation of Internet MIB-II (RFC1213) to ISO/CCITT GDMO
MIB (LaBarre) [IIMCMIB-II]
o Translation of Internet Party MIB (RFC1353) to ISO/CCITT
GDMO MIB (LaBarre) [IIMCPARTY]
o ISO/CCITT-Internet Management Proxy (Chang) [IIMCPROXY]
These memos together comprise a package aimed at integrating
ISO/CCITT-based and Internet-based management systems.
These memos are offered as input to coexistence and
interworking efforts underway throughout the industry,
including organizations such as:
o IETF OSI Internet Management (OIM),
o Network Management Forum Technology Convergence Team,
o X/Open Systems Management (SysMan),
o OIW Network Management Special Interest Group (NMSIG), and
o OSF Management Special Interest Group (MANSIG).
This work was initiated, in part, by NM Forum efforts to
translate RFC 1214 for use with OMNIPoint 1 implementations.
Through this effort, it became obvious that end-to-end
management requires an integrated, unified view of the
managed network, despite differences in management protocol
and information structure. Integrated management can be
facilitated by the development of "proxy" mechanisms which
translate between functionally equivalent service, protocol,
and SMI differences to create this unified view. MIB
translation procedures can be used to support proxy
management, as well as to take advantage of existing MIB
definition and avoid duplication of effort. In this way,
commercial investment in both ISO/CCITT and Internet-based
management technologies can be preserved through deployment
of common methods and tools which support integration.
This overall strategy was outlined in a joint publication
developed by the NM Forum and X/Open entitled "ISO/CCITT and
Internet Management: Coexistence and Interworking Strategy"
[NMFMC92]. The memos included in the IIMC package are
intended as detailed specifications which implement several
of the methodologies identified in this strategy.
Newnan Page 4
Draft ISO/CCITT GDMO MIBs to Internet MIBs 10/9/1992
1.2 Overview
In recent years computer networks have experienced an
explosion in the number and complexity of objects to be
managed. Especially challenging have been environments
where platforms from many vendors must interact and complex
software and hardware configurations must be supported. A
chronic concern for such environments is end-to-end problem
determination and resolution.
Consequently there has been much effort toward standardizing
the management of applications, networks, services and
systems. Despite this major investment, consumers and
standards participants have often found progress
disturbingly slow --- especially in standardizing management
information.
To further complicate matters, different subcultures have
developed differing philosophies and technologies for
network management. Notable examples are the Internet and
ISO/CCITT communities. Although MIB work in these
communities has so far mostly been complementary there is
increasing danger of duplicative, inconsistent and
competitive MIB specification.
Standardisation is a political process and each philosophy
of network management has its merits. However a network
manger rarely has the luxury of being politician or
philosopher; they must pragmatically determine problems in
the network and rapidly resolve them. Typically, service
must be assured in an end-to-end environment management by a
wide range of technologies --- Internet, ISO/CCITT, and
otherwise.
If network management is to meet needs of such network
operators, an "ecumenical" approach to MIBs is required that
marries the work of these standards fora thus providing a
comprehensive and consistent view of networked resources.
An end-to-end approach is needed, one that conceals
differences of protocol and presents the consolidated view
of distributed resources to network operators, system
administrators and programmers.
This implies a common MIB independent of protocol. One way
to arrive at this is to pursue comprehensive and
mechanizable procedures to assist in translating MIB
specifications. This should allow rapid sharing of MIB
specifications while requiring minimal technical and
political intervention by human beings.
What you are reading is a contribution toward this end, a
heuristic procedure to translate from ISO/CCITT GDMO MIB
Newnan Page 5
Draft ISO/CCITT GDMO MIBs to Internet MIBs 10/9/1992
specifications to the Internet MIB macro specifications.
This translation procedure is written with four objectives
in mind:
o Lose as little functionality as possible in translation.
o Minimize need for human involvement to translate.
o Minimize cost to implement dual protocol and proxy-based
applications.
o Support generic network models that span many computer
platforms and network elements.
While an entirely mechanized translation from an ISO/CCITT
GDMO MIB to an Internet MIB is not always possible, the
intent is to mechanize the process as much as possible and
supply reasonable defaults that then may be tempered with
human judgment.
Newnan Page 6
Draft ISO/CCITT GDMO MIBs to Internet MIBs 10/9/1992
In the longer term, MIBs translated in this manner might be
used in conjunction with a proxy architecture that enables
interworking between ISO/CCITT managers and Internet agents
(see Figure 1).
Manager Proxy Agent
+-----------------+ +----------------+ +-------------------+
|+---------------+| |+----++--------+| | +---------------+ |
|| Management || ||GDMO||Internet|| | | Managed | |
|| Applications || ||MIB || MIB || | | Resources | |
|+---------------+| |+----++--------+| | +---------------+ |
| | | |+--------------+| | | |
| | | || Service || | | |
| | | || Emulation || | | |
| | | ||(scoping) || | | |
| | | || (filtering) || | | |
| | | || (operations)|| | | |
|+---------+-----+| |+--------------+| |+--------+--------+|
||ISO/CCITT|GDMO || || Map Protocols | ||Internet|Internet||
|| Manager |MIB || ||CMIS| |SNMP|| || Agent | MIB ||
|+---------+-----+| |+----+----+----+| |+--------+--------+|
| | | | |CMIS | | | | |
| |CMIS Services| | |Services | | | |SNMP "Services"|
| | | | | | | | | |
| | | | | SNMP| | | | |
| | | | |"Services"| | | | |
+-----------------+ +----------------+ +-------------------+
| CMIP | | CMIP | SNMP | | SNMP |
+-----------------+ +----------------+ +-------------------+
^ ^ ^ ^
| | | |
+---------------+ +---------------+
CMIP Messages SNMP Messages
Figure 1. Proxy Architecture
The proxy architecture provides emulation of CMIS services
by mapping to the corresponding SNMP message(s) necessary to
carry out the service request. The service emulation allows
management of Internet objects by an ISO/CCITT manager. The
left hand side of the proxy behaves like an ISO/CCITT agent,
communicating with the ISO/CCITT manager using CMIP
protocols. The right hand side of the proxy behaves like
an Internet manager, communicating with the Internet agent
using SNMP protocols.
The proxy relies on the existence of a pair of directly-
related MIB definitions, where the MIBs have been translated
using heuristic procedures. Currently, the proxy defined in
[IIMCPROXY] is based on the reverse MIB translation
procedures defined in [IIMCIMIBTRANS]. MIBs generated by
this translation process described in this memo cannot be
utilized by the Proxy defined in [IIMCPROXY], although
Newnan Page 7
Draft ISO/CCITT GDMO MIBs to Internet MIBs 10/9/1992
another kind of Proxy could be defined for this purpose in
the future.
This paper assumes the existence of appropriate mechanisms
and procedures for registry of translated objects. What
those procedures might be and where such objects should be
registered, however, is beyond the scope of this
contribution.
1.3 Scope
Following is a procedure for translating management
information bases (MIB's) from ISO/CCITT Guidelines for
Definition of Managed Objects (GDMO) format to that of the
Internet MIB macro format [RFC1212]. The body of this memo
has five parts:
o This introduction, including motivation and objectives for
the translation.
o The translation procedure itself.
o Constraints on use of the SNMP with MIBs translated by
this procedure.
o Summary.
A sample input and translated output are also provided in an
appendix. Examples used throughout the body of the text are
taken from these samples.
The following outstanding issues have been identified for
inclusion in a future update of this memo.
o This procedure is based on current Internet SMI standards,
but should be extended to also cover proposed SNMP-2 (SMP)
SMI standards.
o This procedure currently provides only limited support for
translation of notifications. Additional support should
be provided, including one-time translation of all generic
notifications commonly found in ISO/CCITT GDMO objects.
o An implementation of this translation procedure is now
underway as proof of concept and validation. It is
expected that during implementation, the need for certain
input "pragmas" may be identified, in order to more fully
automate the translation process by inclusion of machine-
readable ASN.1 comments in the ISO/CCITT GDMO MIB input
specification.
1.4 Terms and Conventions
The reader is assumed to be familiar with the vocabularies
of Internet and ISO/CCITT management; in cases where there
might be confusion between the two, words such as
"ISO/CCITT", "GDMO" and "Internet" are inserted to avoid
ambiguity.
Newnan Page 8
Draft ISO/CCITT GDMO MIBs to Internet MIBs 10/9/1992
The following conventions are used throughout the paper:
The terms "class" and "attribute" when expressed in lower
case are generic, referring either to ISO/CCITT MANAGED
OBJECT CLASS's and ATTRIBUTE's (respectively) or their
translated Internet MIB counterparts.
The term "arc" means a single level of branching within an
Abstract Syntax Notation One (ASN.1) registration tree.
The terms "enumerate" and "explode" are used synonymously to
describe the process of translating ATTRIBUTE's and their
values to OBJECT TYPE macros.
A "registry family" is defined to be a set of ASN.1 OBJECT
IDENTIFIER arcs and nodes having a common immediate parent.
Footnotes explore aspects of the translation procedure where
human judgment may be especially advisable, rather than
accepting the raw output of a translator.
2. Translation Procedures
2.1 Relationship to RFC 1212
While translation per se has not been widely investigated,
[RFC1212] does provide advice for adopting MIB objects from
ISO/CCITT GDMO to Internet MIB macros. However, RFC 1212
advises a minimalistic approach to MIB specification,
discouraging carryover of the complexities often found in
ISO/CCITT GDMO specifications. Thus, it does not so much
tell how to translate a MIB as provide advice for borrowing
elements of a ISO/CCITT GDMO specification and constructing
a MIB more in keeping with Internet philosophy.
The translation procedure provided here seeks instead to
provide as faithful a translation as possible, in order to
support the objectives identified in section 1.2 above.
As applicable, the subsections are divided into one or more
of the following parts:
o Relevant advice quoted verbatim from RFC 1212. Beware
that the entire RFC is not quoted here. The reader is
referred to the source for complete text.
o Additional constraints are identified to allow as
comprehensive and mechanizable an approach as possible.
o Discussion of the translation procedure is provided as
guidance to the reader.
2.2 Mapping of Managed Object Classes and Attributes
Newnan Page 9
Draft ISO/CCITT GDMO MIBs to Internet MIBs 10/9/1992
2.2.1 RFC 1212 Advice
... The next step is to categorize the objects into groups.
For experimental MIB's, optional objects are permitted.
However, when a MIB module is placed in the Internet-
standard space, these optional objects are either removed,
or placed in an optional group, which, if implemented, all
objects in the group must be implemented. For the first
pass, it is wisest to simply ignore any optional objects in
the original MIB: experience shows it is better to define a
core MIB module first, containing only essential objects;
later, if experience demands, other objects can be added.
It must be emphasized that groups are "units of conformance"
within a MIB: everything in a group is "mandatory" and
implementations do either whole groups or none.
Next for each managed object class, determine whether there
can exist multiple instances of that managed object class.
If not, then for each of its attributes, use the OBJECT TYPE
macro to make an equivalent definition.
Otherwise, if multiple instances of the managed object class
can exist, then define a conceptual table having conceptual
rows each containing a columnar object for each of the
managed object class's attributes. If the managed object
class is contained within the containment tree of another
managed object class, then the assignment of an object type
is normally required for each of the "distinguished
attributes" of the containing managed object class. If they
do not already exist within the MIB module, then they can be
added via the definition of additional columnar objects in
the conceptual row corresponding to the contained managed
object class.
In defining a conceptual row, it is useful to consider the
optimization of network management operations which will act
upon its columnar objects. In particular, it is wisest to
avoid defining more columnar objects within a conceptual
row, than can fit in a single PDU. As a rule of thumb, a
conceptual row should contain no more than approximately 20
objects. Similarly, or as a way to abide by the "20 object
guideline", columnar objects should be grouped into tables
according to the expected grouping of network management
operations upon them. As such, the content of conceptual
rows should reflect typical access scenarios, e.g., they
should be organized along functional lines such as one row
for statistics and another row for parameters, or along
usage lines such as commonly-needed objects versus rarely-
needed objects.
On the other hand, the definition of conceptual rows where
the number of columnar objects used as indexes outnumbers
the number used to hold information, should also be avoided.
Newnan Page 10
Draft ISO/CCITT GDMO MIBs to Internet MIBs 10/9/1992
In particular, the splitting of a managed object class's
attributes into many conceptual tables should not be used as
a way to obtain the same degree of flexibility/complexity as
is often found in MIB's with a myriad of optionals.
2.2.2 Additional Constraints
This subsection addresses:
o Mapping of MANAGED OBJECT CLASSES and Distinguished Names.
o Mapping of PACKAGE's.
It deals only with the high level procedures for mapping
ISO/CCITT GDMO MANAGED OBJECT CLASSES and ATTRIBUTE's into
Internet MIB macros. Enumeration of individual ATTRIBUTE
values is addressed in subsection 2.3.
2.2.2.1 Mapping of MANAGED OBJECT CLASSES and Distinguished
Names
Translation of a registry family of MANAGED OBJECT CLASS
specifications begins by
o Allocating the root of a registry subtree to contain the
translated objects.
o Assigning a brief naming prefix that distinguishes
contents of a corresponding ASN.1 module generated by the
translation. The module itself is registered at the root
of the registry subtree.
Note: Assignment of naming prefixes and registry
subtrees are required activities, however,
procedures for these are outside the scope of this
paper
For each MANAGED OBJECT CLASS of the input registry family,
define a corresponding Internet MIB object group, its "class
group" Reserve an arc for each of these, keeping the same
relative arc number as is assigned to its equivalent MANAGED
OBJECT CLASS in the input ISO/CCITT GDMO registry. Avoid
registration of ISO/CCITT objects under arc zero (0) by
using the value 16,384 instead.
For each class group define one Internet MIB table ---
a "class table" --- that represents the class as a whole.
Assign this table arc number 1 beneath the arc of the class
group. As will be further discussed in subsection 2.3
below, "side tables" will also often be required for a class
group to support multi-valued ATTRIBUTE's and ATTRIBUTE's
with complex syntaxes. Assign arcs for side tables in
ascending order beneath the arc of the class group beginning
with arc number two.
Newnan Page 11
Draft ISO/CCITT GDMO MIBs to Internet MIBs 10/9/1992
Note: Since all ATTRIBUTE's expand into class
tables or side tables, class groups generated by
the algorithm never contain scalar values.
For each table in the class group, define a table entry and
syntax consistent with RFC 1212 usage for table entries.
For the entries of each class table, begin by allocating the
following conceptual rows and associated arcs:
o Leg 0 beneath the class entry arc is reserved (by the
Internet Structure of Management Information (SMI)).
o Assign leg 1 the delete object, a write-only INTEGER for
which 0 indicates deletion of the corresponding conceptual
row.
o Leg 2 of the arc is assigned the "class entry index," an
INTEGER valued object that provides the unique index for
an entry to the class table. This distinguishes an
instance of an object within its class.
The value of the class entry index is a component of the
"class entry instance." The latter identifies both an
object's class and the unique instance within that class.
This value is used in the translated MIB instead of
Distinguished Name's and ObjectInstance's that represent
relationships between managed objects. As discussed
later, no direct translation of Distinguished Names is
attempted. The class entry instance is arrived at by
concatenating:
-- The OBJECT IDENTIFIER of the class table entry.
-- The value 2 (arc number for the class entry index)
-- The value of the class entry index for the instance in
question.
Note: Where "concatenating" means arriving at a
simple combined sequence of arc values, without
repeat counts or nesting.
Entries of side tables begin in similar fashion:
o Leg 0 is reserved.
o Leg 1 is assigned the delete object.
o Leg 2 of the arc is assigned the class entry index, which
has the same value as the corresponding class entry index
of the class table. This ties side table entries to their
corresponding class table entry.
o Leg 3 of the arc is assigned the first (and typically
only) "value index"; this distinguishes a particular value
of a multi-valued attribute or syntax from the other
values.
o Legs 4-19 of the arc can be assigned if necessary to
provide additional entry value indices. These are needed
only for nested multiply occurring syntaxes.
Newnan Page 12
Draft ISO/CCITT GDMO MIBs to Internet MIBs 10/9/1992
Note: The mapping of multiply occuring elements of
syntaxes is discussed further in later sections.
While supported for completeness, multi-
dimensional values represent an extreme case.
Caution should be used in adopting the raw output
of the algorithm for complex syntaxes.
2.2.2.2 Mapping of PACKAGE's
In reading this section the reader may wish to refer to
Figures 2 and 3, which illustrate the input and output
subtrees of the sample MIB (Appendix A). Note that for this
example, the Trouble Administration module is rooted beneath
an (optional) version arc, to facilitate future releases.
|
| Trouble Report Registry
+-------------------+----------------------+
| |
trMObjectClass trAttribute
| |
| +-----+-----+-----+
troubleReport(5) | | | |
accessTime .... cancel
LocationList(2) RequestedBy
Manager(12)
Figure 2. Sample Input Registration Tree
All else being equal, enumerate ATTRIBUTE's based upon a
left-to-right scanning of the input ISO/CCITT GDMO
specification. ATTRIBUTE's and their values may be
enumerated multiple times in the course of translating a
specification, once for every template in which they are
referenced. For example, if an attribute is included in the
PACKAGE's of two MANAGED OBJECT CLASS's, it will be
enumerated twice in the output: once for each class group.
Enumerate ATTRIBUTE's and their values in the same sequence
as declared in a PACKAGE. These translate to OBJECT TYPE's
that, unless otherwise noted below, receive successive arcs
in the output registry tree.
Enumerate all components of base classes before those of
their derivative classes. Thus where a package is refined
by a subclass, first enumerate all components of the base
class, keeping the sequence of the base class PACKAGE's.
Explode ATTRIBUTE's of a derivative class later, enumerating
in the order of specification for that class.
Newnan Page 13
Draft ISO/CCITT GDMO MIBs to Internet MIBs 10/9/1992
|
+Network Version
|Management
|V1 (1)
.............................|..............................
+Trouble ASN.1
|Administration Module
|(4)
.............................|..............................
+trTrouble Class
|Report(5) Group
+-------------------------------+
| |
...............|...............................|............
Class Tables +trTrouble +trTrouble
and Side |ReportTable (1) |ReportAccess
Tables | |TimeLocation
| |ListTable(2)
...............|...............................|............
Class and +trTrouble +trTrouble
Side Table |ReportTableEntry (1) |ReportAccess
Entries | |TimeLocation
| |ListTable
| |Entry(1)
...............|...............................|............
Enumerated +--trTATroubleReportDelete (1) +--(etc)
Attribute |
Values +--trTATroubleReportIndex (2)
|
+--trTATroubleReportCancel
RequestedByManager (20)
Figure 3. Sample Output Registration Tree
Reserve at least ten arcs for future growth for each level
of derivation, i.e., take the highest arc number of the base
class, add ten and round upwards to the nearest even
multiple of ten, to determine the first arc number assigned
to the derivative class.
For multiple inheritance, enumerate contents of base classes
left-to-right and depth first, i.e., enumerate all
components attributable to one immediate base class before
proceeding to the next. In this case also reserve arcs for
future growth by adding ten and rounding up to the nearest
even multiple of ten.
2.2.3 Discussion
2.2.3.1 Mapping of MANAGED OBJECT CLASSES and
Distinguished Names
Newnan Page 14
Draft ISO/CCITT GDMO MIBs to Internet MIBs 10/9/1992
RFC 1212 recommends defining a table for every object group
that can be multiply occurring within an agent. It would be
very unusual for a MANAGED OBJECT CLASS not to have
potentially multiple occurrences, especially given a generic
network model that spans systems. Thus to simplify
translation, all object classes map to tables. This
approach has several advantages:
o It supports default values for new object instances.
o It is easy to mechanize, since there is no need to
recognize special cases that are not multiply occurring.
o It simplifies programming of proxy or dual protocol
agents, since the programmer is dealing with basically the
same syntax for scalar items, regardless of protocol.
The last point applies to both programming effort and
processing overhead. To the extent the elements of syntax
are mapped one-to-one, and underlying syntax is similar or
identical for both protocols, they can be manipulated with
common code and common data structures. This simplifies
translation from both the programming and run-time
perspectives.
The notion of a class entry instance is introduced since
direct translation of Distinguished Name's appears
impractical for the following reasons:
o A possible ambiguity arises since NAME BINDING's allow
different object instances of the same MANAGED OBJECT
CLASS to exist under parent objects of different classes.
Likewise, different classes can have the same syntax for
their distinguished attribute(s). Thus, a concatenation
of attribute values is not sufficient to uniquely
distinguish an object instance.
o NAME BINDING's allow different instances of the same class
to be subordinate to different types of parent and even
allow instances of a class to be contained recursively
within others of the same class. Thus, in directly
translating the DN one cannot assume a fixed sequence of
parameters as required for by the INDEX clause (DN's for
different instances of the same object class may be have
different numbers of RDN's).
o Both problems could in theory be circumvented by fully
translating the Distinguished Name and incorporating
AttributeType's as well as AttributeValue's into the
subidentifier OID (in which case the INDEX clause would
only need to specify one index, an OBJECT IDENTIFIER).
While the latter is in theory possible, it would result in
exceedingly verbose subidentifiers, on the order of 70
octets rather than 7. This is of serious concern due to PDU
length restrictions for SNMP. RFC 1212 proposes a "rule of
twenty," i.e., no more than twenty attributes per operation.
That guideline was designed for relatively compact
Newnan Page 15
Draft ISO/CCITT GDMO MIBs to Internet MIBs 10/9/1992
subidentifiers. When using an RDN for an INDEX, this would
more likely amount to a "rule of three," which is why
comprehensive translation of the ISO/CCITT DN to an INDEX
appears practical.
For the following reasons, attributes of TOP are not
directly translated into OBJECT TYPE's:
o Most of these notions will be unfamiliar to the Internet
user and thus their presence would add questionable value.
o Multi-valued attributes would require additional side
tables for all object class groups, which would be
cumbersome.
o Managed object class is implicit in the class prefix thus
does not require a special attribute.
o An allomorphs attribute is supported in ISO/CCITT to allow
dynamic recognition of allomorphs which are supported by
an instance. Since Internet MIB does not support
allomorphs at all --- much less dynamic ones ---
there is no reason to list them.
o There is no notion of NAME BINDING's for Internet MIB.
NAME BINDING rules must still be enforced for the
translated MIB, and should be documented via comments in
the Internet MIB specifications. However, there seems to
be no point in providing this attribute to the Internet
user in the run time environment.
o Presence or absence of conditional packages can be
detected using a GetNextRequest request and determining
whether the conceptual rows returned are the same as
expected. No special attribute is needed for this
purpose.
2.2.3.2 Mapping of PACKAGE's
Left-to-right sequential enumeration is the obvious approach
for a mechanized translation procedure.
While ISO/CCITT GDMO allows ATTRIBUTE's and ASN.1 syntaxes
to be referenced in multiple places and thus be shared,
Internet MIB format does not. Thus one or more OBJECT
TYPE's must be specified for each template in which they are
referenced. The consequent explosion of enumerated
ATTRIBUTE's and ASN.1 syntaxes is a major motivation for a
mechanizable procedure and mechanized translation aids.
2.3 Mapping to the SYNTAX clause
2.3.1 RFC 1212 Advice
When mapping to the SYNTAX clause of the OBJECT TYPE macro:
(1) An object with BOOLEAN syntax becomes an INTEGER taking
either of values true(1) or false(2).
Newnan Page 16
Draft ISO/CCITT GDMO MIBs to Internet MIBs 10/9/1992
(2) An object with ENUMERATED syntax becomes an INTEGER,
taking any of the values given.
(3) An object with BIT STRING syntax containing no more
than 32 bits becomes an INTEGER defined as a sum; otherwise
if more than 32 bits are present, the object becomes an
OCTET STRING, with the bits numbered from left-to-right, in
which the least significant bits of the last octet may be
"reserved for future use."
(4) An object with a character string syntax becomes either
an OCTET STRING or a DisplayString, depending on the
repertoire of the character string.
(5) An non-tabular object with a complex syntax, such as
REAL or EXTERNAL, must be decomposed, usually into an OCTET
STRING (if sensible). As a rule, any object with a
complicated syntax should be avoided.
(6) Tabular objects must be decomposed into rows of
columnar objects.
2.3.2 Additional Constraints
2.3.2.1 Simple Input Syntax
Following are rules for translating non-constructed (scalar)
syntax.
For ENUMERATED types, transform to INTEGER, with values of
(0) mapped to (32767).
Where ISO/CCITT management allows certain forms to be
present or not present on a case by case basis (i.e.,
conditional packages and ASN.1 OPTIONAL and CHOICE syntaxes)
enumerate all possibilities and allow corresponding
conceptual columns to be conditionally present on a row-by-
row basis.
For CHOICE types, provide an OBJECT TYPE for every
alternative and populate exactly one of these alternatives
per conceptual row.
For ASN.1 string types, use DisplayString whenever the
character set actually expected in the element is a subset
of DisplayString, else specify OCTET STRING.
In general, treat a constructed type that contains no more
than one scalar (e.g., various forms of string
specialization) as if it were the contained scalar.
ANY's and ANY DEFINED BY's map to OCTET STRING's that
contain the BER encoded values of the corresponding ASN.1
types.
Newnan Page 17
Draft ISO/CCITT GDMO MIBs to Internet MIBs 10/9/1992
2.3.2.2. Complex Input Syntax
Map compound constructors (those that may contain multiple
scalars) to SEQUENCES --- including SET syntaxes.
Expansion of compound constructors sometimes requires
definition of "side tables," ancillary tables within the
object group that supplement the main table representing the
ISO/CCITT GDMO managed object class. The rules for making
side tables are applied recursively and are as follows:
o For a given level of nesting, if the ISO/CCITT GDMO ASN.1
syntax is SEQUENCE (not SEQUENCE OF) or SET (not SET OF)
enumerate its scalar elements "in-line" without
constructing a new side table, and otherwise treat them as
if scalars.
o Otherwise (SEQUENCE OF or SET OF) enumerate the scalar
elements of the SEQUENCE or SET in a new side table that
is a "child" of the current table. Since this may happen
recursively, a side table may be a child of another side
table.
o The INDEX of a child table is that of its parent
concatenated with a value index that uniquely
distinguishes instances within the child table.
2.3.3 Discussion
2.3.3.1 Simple Input Syntax
Internet SMI precludes a value of zero and some compilers
won't take it. 32767 is a number that practically any
machine architecture can support and is large enough so it
should not conflict with any enum actually specified.
Allowing optional conceptual columns within rows is not
consistent with the philosophy of RFC 1212, but neither are
the MIB's the procedure seeks to translate. However,
optional columns can be accommodated by SNMP using the
GetNext request. In that case protocol returns inconsistent
object ID prefixes for any non-present objects, rather than
an error condition.
2.3.3.2 Complex Input Syntax
This is the messiest part of the translation process but
cannot be avoided given that the ISO/CCITT GDMO information
model is to be carried over. One way of looking at this is
that constructed types are put in third normal form, i.e.,
broken up into a set of flat tables each of which has a
unique key.
There is a convention in the Internet world that the key of
a table references only attributes contained within that
table. The translation procedure honors that practice by
Newnan Page 18
Draft ISO/CCITT GDMO MIBs to Internet MIBs 10/9/1992
defining distinct OBJECT TYPE's for all indices of side
tables, although though a child table only has only one
index with a different value from its parent's.
There may very well be a "natural key" for multi-valued
syntax, e.g., an address or name. In this case, an
artificial index may be inappropriate. Human judgment must
weigh whether there is a "natural" key and whether the
length of the associated subidentifier would be permissible
for purposes of indexing.
Note: It is not recommended that natural keys be
used for the INDEX parameter of a class table as
that will result in very long subidentifiers and
complicate allocation of indexes for new object
creation. Human judgement can be used to
supplement class entry indices with side tables
that provide secondary indices that support access
based on natural keys.
There is no need to actually access OBJECT TYPES that
correspond to table indices, you would have to know them ---
first to read them, and they can't be changed. Therefore,
their ACCESS clauses specify not-accessible.
2.4 Generation of Internet MIB Identifiers
2.4.1 Translation Procedure
This discussion has two parts:
o Definition of notation for mapping rules.
Rules for name mapping, with examples. o
2.4.1.1 Notation
<ASN.1 id> Identifier of a production rule
specified using Abstract Syntax
Notation One (ASN.1), e.g.,
"AccessTimeLocationList."
<ATTRIBUTE id> Identifier used for ATTRIBUTE
template, e.g., "Trouble
ReportCancelRequestedByManager."
<MANAGED OBJECT Identifier used for MANAGED OBJECT
CLASS template, e.g.,
CLASS id> "TroubleReport."
<module prefix> An arbitrary literal assigned to the
ASN.1 module to be generated, e.g.,
"t1TA."
Newnan Page 19
Draft ISO/CCITT GDMO MIBs to Internet MIBs 10/9/1992
<n> A decimal string literal indicating
the dimension represented by a value
index of a side table. The first
dimension corresponds to the instance
of the managed object (i.e., class
index) and <n> is not concatenated in
its name. <n> is null valued for the
second dimension, which is usually
the greatest dimension, i.e., the
standard multi-valued attribute.
Values of <n> for higher dimensions
are decimal literals assigned in
ascending sequence starting with "3,"
i.e., "3," "4," etc. Note: This
option is included for completeness.
This is a good example of a case
where human judgement should be used
before carrying over full
functionality between MIB's.
Figure 4. Variables for Generating Identifiers
The following notation is used to specify mapping rules:
Symbols enclosed in quotes are literals.
Symbols enclosed in angle brackets ("<>") are variables
that have different string values depending on instance or
context. Figure 4 describes the variables.
Double upended bars ("||") signify the concatenation
operator. For this operator, literals are concatenated
without modification. When concatenating a variable
however, its first character of its value string is
promoted to upper case. Strings are concatenated without
intervening punctuation or white space to arrive at the
resulting identifier.
2.4.1.2. Mapping Rules
The following table provides mapping rules for generating
Internet MIB identifiers. An example is provided for each
rule, based on the sample inputs and outputs of Appendix A.
Identifier Syntax and Example
class table <module prefix>||<MANAGED OBJECT CLASS
id>||"Table"
e.g., t1TATroubleReportTable
class (table) <module prefix>||<MANAGED OBJECT CLASS
entry id>||"TableEntry"
e.g., t1TATroubleReportTableEntry
class entry <module prefix> || <MANAGED OBJECT CLASS id>
delete flag || "Delete"
e.g., t1TATroubleReportDelete
Newnan Page 20
Draft ISO/CCITT GDMO MIBs to Internet MIBs 10/9/1992
class entry <module prefix> || <MANAGED OBJECT CLASS id>
index of class || "Index"
table e.g., t1TATroubleReportIndex
conceptual row <module prefix> || <MANAGED OBJECT id>
CLASS
of class table || <ATTRIBUTE id> || <ASN.1 id>
e.g., t1TATroubleReport
side table <module prefix> || <MANAGED OBJECT CLASS id>
|| <ATTRIBUTE id> || <ASN.1 id>* ||
"Table"
e.g.,
t1TATroubleReportAccessTimeLocationList
Table
side (table) <module prefix> || <MANAGED OBJECT CLASS id>
entry ||<ATTRIBUTE id> || "TableEntry"
e.g.,
t1TATroubleReportAccessTimeLocationList
TableEntry
side entry <module prefix> || <MANAGED OBJECT CLASS id>
delete flag || "Delete"
e.g.,
t1TATroubleReportAccessTimeLocationList
Delete
class entry <module prefix> || <MANAGED OBJECT CLASS id>
index of side || <ATTRIBUTE id> || "ClassIndex"
table e.g.,
t1TATroubleReportAccessTimeLocationList
ClassIndex
value index of <module prefix> || <MANAGED OBJECT CLASS id>
side table || <ATTRIBUTE id> || "ValueIndex" ||
<n>
e.g.,
t1TATroubleReportAccessTimeLocationList
ValueIndex
Figure 5. Mapping Rules for Generating Identifiers
* Note: The <ASN.1 id> is only present in the
names of side table objects when its presence is
necessary to unambiguously distinguish the table
in question.
The identifier for the syntax for a (class or side) table
entry is the same as that of the table entry itself except
the first character is promoted to upper case, e.g.,
"T1TATroubleReportTableEntry."
2.4.2 Discussion
This approach is verbose but can be mechanized and
ambiguities and collisions should be rare. It has the
further advantage that names can be used for C language
program variables without further manipulation.
Newnan Page 21
Draft ISO/CCITT GDMO MIBs to Internet MIBs 10/9/1992
Separating constituent ids with hyphens would increase
readability and decrease likelihood of ambiguity.
Unfortunately, many Internet MIB compilers do not allow
this.
In cases where the same ATTRIBUTE appears in more than one
PACKAGE included in a MANAGED OBJECT CLASS, manual
intervention is necessary to assign distinct identifiers for
the corresponding OBJECT TYPE's.
2.5 Mapping to the ACCESS clause
2.5.1 RFC 1212 Advice
This is straight-forward.
2.5.2 Discussion
Note that ADD-REMOVE and REPLACE map to "write," while GET
maps to "read." There is no direct mapping to SET-TO-
DEFAULT, since SNMP requires values be explicitly set for
existing objects. PERMITTED VALUES are not directly mapped
in the Internet MIB but need to be understood by the
management station.
2.6 Mapping to the STATUS clause
2.6.1 RFC 1212 Advice
This is usually straight-forward; however, some osified-MIBs
use the term "recommended." In this case, a choice must be
made between "mandatory" and "optional."
2.6.2 Additional Constraints
The translation procedure always uses mandatory.
2.6.3 Discussion
Human judgment can qualify this as necessary.
2.7 Mapping to the DESCRIPTION clause
2.7.1 RFC 1212 Advice
This is straight-forward: simply copy the text, making sure
that any embedded double quotation marks are sanitized
(i.e., replaced with single-quotes or removed).
2.8 Mapping to the REFERENCE clause
2.8.1 RFC 1212 Advice
Newnan Page 22
Draft ISO/CCITT GDMO MIBs to Internet MIBs 10/9/1992
This is straight-forward: simply include a textual reference
to the object being mapped, the document which defines the
object, and perhaps a page number in the document.
2.8.2 Additional Constraints
The translation procedure (automatically) provides the name
and object identifier of the attribute.
2.9 Mapping to the INDEX clause
2.9.1 RFC 1212 Advice
Decide how instance-identifiers for columnar objects are to
be formed and define this clause accordingly.
2.9.2 Additional Constraints
Use the class entry index's for the table and any containing
table, as discussed previously. This keeps the index for
any particular kind of table constant and predictable.
2.10 Mapping to the DEFVAL clause
2.10.1 RFC 1212 Advice
Decide if a meaningful default value can be assigned to the
object being mapped, and if so, define the DEFVAL clause
accordingly.
2.10.2 Additional Constraints
Please see the previous sections on mapping of managed
objects and syntaxes.
2.11 Translation of Actions
2.11.1 RFC 1212 Advice
2.11.1.1 General Advice
Actions are modeled as read-write objects, in which writing
a particular value results in the action taking place.
Usually an INTEGER syntax is used with a distinguished value
provided for each action that the object provides access to.
In addition, there is usually one other distinguished value,
which is the one returned when the object is read.
2.11.1.2 Mapping to the ACCESS clause
Always use read-write.
2.11.1.3 Mapping to the STATUS clause
Newnan Page 23
Draft ISO/CCITT GDMO MIBs to Internet MIBs 10/9/1992
This is straight-forward.
2.11.1.4 Mapping to the DESCRIPTION clause
This is straight-forward: simply copy the text, making sure
that any embedded double quotation marks are sanitized
(i.e., replaced with single-quotes or removed).
2.11.1.5 Mapping to the REFERENCE clause
This is straight-forward: simply include a textual reference
to the action being mapped, the document which defines the
action, and perhaps a page number in the document.
2.11.2 Discussion
This is one of the areas where mechanization can at best be
an aid, rather than an automatic solution, to translation.
The RFC 1212 advice provides a point of departure in this
regard.
2.12 Translation of Notifications
2.12.1 Approach
Notifications are not translated algorithmically. However,
traps corresponding to standard notifications, are provided
in the ISO/CCITT Compatibility MIB defined in Appendix B.
These are only used for a managed object if the notification
is specified for its object class in the base standard, and
then if there is a clear need (since there is no event
filtering mechanism in SNMP). Objects corresponding to
mandatory parameters of the ISO/CCITT notifications are also
included in the ISO/CCITT Compatibility MIB. These objects
are referenced by the VARIABLES clauses of traps. An
additional object in this group, ocReferencedInstance, gives
the class entry instance of the object the notification is
about.
2.12.2 Discussion
These are not translated automatically but are dealt with on
a case by case basis. The ISO/CCITT Compatibility MIB
provides mapped subsets of the most common types of
notification.
2.13 Translation of Delete Operations
2.13.1 RFC 1212 Advice
Nonetheless, it is highly useful to provide a means whereby
a conceptual row may be removed from a table. In MIB-II,
this was achieved by defining, for each conceptual row, an
integer-value columnar object. If a management station sets
Newnan Page 24
Draft ISO/CCITT GDMO MIBs to Internet MIBs 10/9/1992
the value of this object to some value, usually termed
"invalid," then the effect is one of invalidating the
corresponding row in the table. However, it is an
implementation-specific matter as to whether an agent
removes an invalidated entry from the table. Accordingly,
management stations must be prepared to receive tabular
information from agents that corresponds to entries not
currently in use. Proper interpretation of such entries
requires examination of the columnar object indicating the
in-use status.
2.13.2 Discussion
To simplify mechanized translation, the DELETE operation is
provided for all tables, rather than trying to determine
which ones support manager-initiated DELETE operations.
2.14 Translation of Create Operations
2.14.1 RFC 1212 Advice
It is also highly useful to have a clear understanding of
how a conceptual row may be added to a table. In Internet,
at the protocol level, a management station issues an SNMP
set operation containing an arbitrary set of variable
bindings. In the case that an agent detects that one or
more of those variable bindings refers to an object instance
not currently available in that agent, it may, according to
the rules of the SNMP, behave according to any of the
following paradigms:
(1) It may reject the SNMP set operation as referring to
non-existent object instances by returning a response with
the error-status field set to "noSuchName" and the error-
index field set to refer to the first vacuous reference.
(2) It may accept the SNMP set operation as requesting the
creation of new object instances corresponding to each of
the object instances named in the variable bindings. The
value of each (potentially) newly created object instance is
specified by the "value" component of the relevant variable
binding. In this case, if the request specifies a value for
a newly (or previously) created object that it deems
inappropriate by reason of value or syntax, then it rejects
the SNMP set operation by responding with the error-status
field set to badValue and the error-index field set to refer
to the first offending variable binding.
(3) It may accept the SNMP set operation and create new
object instances as described in (2) above and, in addition,
at its discretion, create supplemental object instances to
complete a row in a conceptual table of which the new object
instances specified in the request may be a part.
Newnan Page 25
Draft ISO/CCITT GDMO MIBs to Internet MIBs 10/9/1992
It should be emphasized that all three of the above
behaviors are fully conformant to the SNMP specification and
are fully acceptable, subject to any restrictions which may
be imposed by access control and/or the definitions of the
MIB objects themselves.
2.14.2 Additional Constraints
Be very sparing in allowing Internet manager initiated
object creation. A table of parents and a table of name
bindings are provided in the ISO/CCITT Compatibility MIB so
that a parent can be specified when creating an object.
2.14.3 Discussion
To create an object mapping into the ISO/CCITT world
requires that its parent be known, hence the parent table.
A child table is also provided to allow general navigation
of the MIB tree. The name binding table is necessary to
determine the object identifier associated with each
parent/child binding.
An SNMP SetRequest needs to contain enough information to
create an internally consistent object from the ISO/CCITT
perspective. The SNMP PDU size restriction could be a
problem here.
3 Constraints on SNMP Usage
The following constraints apply when using SNMP with a MIB
translated by this procedure.
3.1 Approach.1 Approach
The following assumptions about use of the SNMP are made to
facilitate MIB translation:
o The management station will expect that conditional
attributes may not be present on a per conceptual row
basis and will act appropriately, e.g., use GetNextRequest
to test for presence.
o The management station will expect that access actually
granted may be less than stated in the MIB specification
due to dynamic access controls; in such cases it may
receive error-status of readOnly --- even for an SNMP
GetRequest.
o A management station creating a new entry in a class or
side table must first acquire an appropriate index for
doing so. This is accomplished by reading the value of
either the ocNextLocallyUniqueIndex object or
ocNextGloballyUniqueIndex object in the "ISO/CCITT
Compatibility MIB" (listed in the appendices). Both
objects return a unique subidentifier when read (i.e., a
different value each time). The subidentifier returned by
Newnan Page 26
Draft ISO/CCITT GDMO MIBs to Internet MIBs 10/9/1992
ocNextLocallyUniqueIndex is guaranteed to be unique
within an agent, while a subidentifier returned by the
ocNextGloballyUniqueIndex is guaranteed unique across the
network.
o Creation of a class or side table entry requires that the
associated SNMP SetRequest PDU include
-- a valid preallocated subidentifier for that table,
-- initial values for those attributes that must be
present (which however may be allowed to default)
and
-- in the case of a class table entry, class entry
instance of a valid parent object to be inserted in
the parent table.
-- If any of these conditions are not met, noSuchName
error-status is returned.
o If a management station attempts to delete an object or
attribute value for which deletion is not permitted (for
any reason) error-status of readOnly is returned.
o A management station must be prepared to receive badValue
error-status when a SetRequest operation attempts to set
an attribute to a value inconsistent with other attribute
values according to the object's BEHAVIOR or PERMITTED
VALUES specifications.
3.2 Discussion
To support create operations requires that the manager
somehow supply a unique subidentifier. Rather than sub-
allocate index ranges to different managers or administer
pools on a per-table basis, it seems simplest to have a
generic pool administered by the agent on behalf of all
managers.
As regards error-status values, a "bending" of the rules of
SNMP is necessary to map functionality not really supported
in the protocol. Thus an off-the-shelf manager should be
able to interoperate with an agent that implements a
translated MIB but usage of the PDUs will not be entirely
conventional. This is particularly true for usage of error-
status.
4 Summary
Given certain assumptions about the use of SNMP (section 3)
and the ancillary ISO/CCITT Compatibility MIB (appendix B),
this procedure allows mechanized translation of most
functionality found in ISO/CCITT MIBs to the world of SNMP.
The algorithm preserves basic capability to navigate
ISO/CCITT object relationships, i.e.,
o Location of parents (immediately containing objects),
Newnan Page 27
Draft ISO/CCITT GDMO MIBs to Internet MIBs 10/9/1992
o Location of children (immediately contained objects), and
o Location of referenced objects.
This approach preserves the capability to create new object
instances and attribute values, even for generic network
models that subsume multiple computer systems and network
elements.
Areas in which significant functionality is lost in
translation include:
o Notification: a minimalistic set of capabilities are
provided for basic notifications in the ISO/CCITT
Compatibility MIB. No attempt is made to provide for
filtering or logging of notifications.
o Actions: these must be dealt with manually, on a case by
case basis.
o Scoping and filtering: only rudimentary tools are provided
for navigating the translated MIB's using SNMP.
5 Acknowledgments
The author wishes to express gratitude to Keith McCloghrie
for his extremely timely and expert assistance with the
Trouble Administration translation effort, also, to Ken
Hunter of Hewlett-Packard Company and Al Vincent of U S WEST
Communications, Inc. who translated the MIB and made it
work. In addition, thanks are due to the following
individuals who participated in the generation of the IIMC
package:
Lisa Phifer - Bellcore
April Chang - NetLabs
Jock Embry - Opening Technologies
Steve Ng - MPR Teltech
Lee LaBarre - Mitre
References
[ISO8824] ISO/IEC IS 8824: Information Technology -
Open System Interconnection - Specification of Abstract
Syntax NotationOne (ASN.1),1990.
[ISO8825] ISO/IEC IS 8825: Information Technology -
Open System Interconnection -Specification of Basic
Encoding Rules for Abstract Syntax Notation One
(ASN.1),1990.
Newnan Page 28
Draft ISO/CCITT GDMO MIBs to Internet MIBs 10/9/1992
[ISO7498-4] ISO/IEC IS 7498-4, Information Processing
Systems - Open Systems Interconnection -Basic Reference
Model Part 4 - Management Framework, 1989.
[ISO9595] ISO/IEC IS 9595, Information Technology -
Open SystemInterconnection - CommonManagement Information
Service Definition, 1991.
[ISO9596-1] ISO/IEC IS 9596-1, Information Technology -
Open Systems Interconnection - CommonManagement
Information Protocol - Part 1: Specification, 1991.
[ISO10165-1] ISO/IEC IS 10165-1: Information Technology -
Open Systems Interconnection - Structureof Management
Information - Part 1: Management Information Model, 1991.
[ISO10165-2] ISO/IEC IS 10165-2: Information Technology -
Open Systems Interconnection -Structure of Management
Information - Part 2:Definition of Management
Information, 1992.
[ISO10165-4] ISO/IEC IS 10165-4: Information Technology -
Open Systems Interconnection -Structure of Management
Information - Part 4: Guidelines for the Definition of
Managed Objects, 1991.
[RFC1052] RFC 1052, Cerf, V., IAB Recommendations for
the Development of Internet Network Management Standards,
April 1988.
[RFC1109] RFC 1109, Cerf, V., Report of the Second Ad
Hoc Network Management Review Group, August 1989.
[RFC1155] RFC1155, M. Rose and K. McCloghrie, Structure
and Identification of ManagementInformation for TCP/IP
based internets, May 1990.
[RFC1157] RFC 1157, J.D. Case, M.S. Fedor, M.L.
Schoffstall, C. Davin, Simple NetworkManagement Protocol
(SNMP), May 1990.
[RFC1212] RFC1212, M. Rose, K. McCloghrie - Editors,
Concise MIB Definitions, March 1991.
[RFC1213] Network Management of TCP/IP-based internets:
MIB-II, March 1991.
[RFC1214] RFC1214, L. LaBarre - editor, OSI Internet
Management:Management Information Base, April 1991.
[RFC1215] RFC1215, M. Rose - Editor, Management A
convention for Defining Traps for usewith the SNMP, March
1991.
Newnan Page 29
Draft ISO/CCITT GDMO MIBs to Internet MIBs 10/9/1992
[RFC1353] RFC1353, K. McCloghrie, J.R. Davin, J.M.
Galvin, Definitions ofManaged Objects for SNMP Parties,
July 1992.
[SMPCOEX] J.D. Case, K. McCloghrie, M.T. Rose, S.L.
Waldbusser, Coexistance between the Internet-standard
Network Management Framework and the Simple Management
Protocol (SMP)Framework, Internet-draft, October 1992.
[SMPPROT] J.D. Case, K. McCloghrie, M.T. Rose, S.L.
Waldbusser, ProtocolOperations for the Simple Management
Protocol (SMP) Framework, Internet-draft, October 1992.
[SMPSMI] J.D. Case, K. McCloghrie, M.T. Rose, S.L.
Waldbusser, ProtocolStructure of Management Information
for the Simple Management Protocol (SMP) Framework,
Internet-draft, October 1992.
[SMPMIB] J.D. Case, K. McCloghrie, M.T. Rose, S.L.
Waldbusser, ManagementInformation Base for the Simple
Management Protocol (SMP) Framework, Internet-draft,
October1992.
[SMPTC] J.D. Case, K. McCloghrie, M.T. Rose, S.L.
Waldbusser, TextualConventions for the Simple Management
Protocol (SMP) Framework, Internet-draft, October1992.
[IIMCIMIBTRANS] L. LaBarre, ISO/CCITT Integrated Management
(OIM): Translation of Internet MIBs to ISO/CCITT GDMO
MIBs, October, 1992.
[IIMCPARTY] L. LaBarre, ISO/CCITT and Internet Management
Coexistence:Translation of Internet Party MIB (RFC1353)
to ISO/CCITT GDMO MIB, October 1992.
[IIMCMIB-II] L. LaBarre, ISO/CCITT and Internet Management
Coexistence:Translation of Internet MIB-II (RFC1213) to
ISO/CCITT GDMO MIB, October 1992.
[IIMCPROXY] A. Chang, ISO/CCITT and Internet Management
Coexistence: ISO/CCITT to Internet Management Proxy,
October 1992.
[NMFMC92] Network Management Forum: Forum TRxxx,
ISO/CCITT and Internet Management Coexistence, NM Forum,
Issue 1.0, Draft 6, October, 1992.
[T1M192] ANSI T1M1.5, Operations, Administration and
Provisioning (OAM&P) --- Services for Interfaces between
Operations Systems across Jurisdictional Boundaries to
support Fault Management --- Trouble Administration,
T1LB.262R3-1991, January 13, 1992.
Newnan Page 30
Draft ISO/CCITT GDMO MIBs to Internet MIBs 10/9/1992
[USWE92] U S WEST Communications, Inc., U S WEST
Network Interface Specification --- MEDIACC Trouble
Administration (TA), Document Number 77302,* Issue A, May
1992.
* U S WEST Business Resources, Inc., Manager---Information
Release, 1801 Califronia St., Room 1340, Denver CO 80202;
303 298 0117.
Newnan Page 31
Draft ISO/CCITT GDMO MIBs to Internet MIBs 10/9/1992
Appendix A Abridged Example
Following is a fairly brief example that illustrates some
but not all aspects of the translation procedure.
The reader can find a more comprehensive example of MIB
translation in [T1M192] and [USWE92], from which
specfications this abridged example is adapted. The reader
will note that this example is highly abridged and differs
in some other respects from those two specifications.
A.1 Input ISO/CCITT Management Information Base
troubleReport MANAGED OBJECT CLASS
DERIVED FROM "T1M1":top; -- ANSI T1M1 variant of top
CHARACTERIZED BY
troubleReportPkg PACKAGE
ATTRIBUTES
cancelRequestedByManager GET-REPLACE
DEFAULT VALUE
TroubleModule.troubleReportCancelRequestedByManagerDefault,
managedObjectInstance GET,
receivedTime GET,
troubleFound GET;
NOTIFICATIONS
"Rec. X.721 | ISO/IEC 10165-2 : 1992":objectCreation,
"Rec. X.721 | ISO/IEC 10165-2 : 1992":objectDeletion,
"T1LB-91-263R1":troubleHistoryEventNotification;;;
CONDITIONAL PACKAGES
troubleReportaccessTimeLocationListPkg PACKAGE
ATTRIBUTES
accessTimeLocationList GET-REPLACE;;
PRESENT IF "an instance supports it.,",
troubleReportperceivedTroubleSeverityPkg PACKAGE
ATTRIBUTES
perceivedTroubleSeverity GET-REPLACE;;
PRESENT IF "an instance supports it.";
REGISTERED AS { trMObjectClass 5};
accessTimeLocationList ATTRIBUTE
WITH ATTRIBUTE SYNTAX
TroubleModule.ServiceLocationList;
BEHAVIOUR
accessTimeLocationListBehaviour BEHAVIOUR
DEFINED AS
"The Access Time Location list attribute
identifies the set or subset of service locations
Newnan Page 32
Draft ISO/CCITT GDMO MIBs to Internet MIBs 10/9/1992
for which the Location Access Hours attribute
values are valid.";
;
REGISTERED AS { trAttribute 2};
cancelRequestedByManager ATTRIBUTE
WITH ATTRIBUTE SYNTAX
TroubleModule.CancelRequestedByManager;
MATCHES FOR EQUALITY;
BEHAVIOUR
cancelRequestedByManagerBehaviour BEHAVIOUR
DEFINED AS
"The Cancel Requested By Manager attribute
indicates whether the manager hasinitiated the
process to cancel a Trouble Report.";
;
REGISTERED AS {trAttribute 12};
managedObjectInstance ATTRIBUTE
WITH ATTRIBUTE SYNTAX
TroubleModule.ManagedObjectInstance;
MATCHES FOR EQUALITY;
BEHAVIOUR
managedObjectInstanceBehaviour BEHAVIOUR
DEFINED AS
"The Managed Object Instance attribute indicates
the CNM Service object classinstance or the GNM
telecommunications network resource instance
associated with aparticular trouble report
instance.";
;
REGISTERED AS {trAttribute 29};
perceivedTroubleSeverity ATTRIBUTE
WITH ATTRIBUTE SYNTAX
TroubleModule.PerceivedTroubleSeverity;
MATCHES FOR EQUALITY;
BEHAVIOUR
perceivedTroubleSeverityBehaviour BEHAVIOUR
DEFINED AS
"The Perceived Trouble Severity attribute allows
the manager to indicate the effect of the trouble
on the managed object being reported.";
;
REGISTERED AS {trAttribute 32};
receivedTime ATTRIBUTE
WITH ATTRIBUTE SYNTAX TroubleModule.ReceivedTime;
MATCHES FOR ORDERING;
BEHAVIOUR
receivedTimeBehaviour BEHAVIOUR
DEFINED AS
"The Received Time attribute indicates the date
and time when a trouble report was entered.";
Newnan Page 33
Draft ISO/CCITT GDMO MIBs to Internet MIBs 10/9/1992
;
REGISTERED AS {trAttribute 33};
troubleFound ATTRIBUTE
WITH ATTRIBUTE SYNTAX TroubleModule.TroubleFound;
BEHAVIOUR
troubleFoundBehaviour BEHAVIOUR
DEFINED AS
"The Trouble Found attribute specifies an
enumerated code value, which identifies the
problem resolved. This field will be copied into
the trouble history information.";
;
REGISTERED AS {trAttribute 45};
troubleHistoryEventNotification NOTIFICATION
WITH INFORMATION SYNTAX
TroubleModule.TroubleHistoryInfo;
REGISTERED AS {trNotification 1};
TroubleModule DEFINITIONS ::=
-- TroubleModule {...troubleModule(x)}
BEGIN
IMPORTS
AdditionalTroubleInfo,
CancelRequestedByManger,
CloseoutVerification,
CommitmentTime,
PerceivedTroubleSeverity,
TroubleFound,
TroubleReportNumberList,
TroubleType FROM GNMTA
ObjectInstance FROM CMIP-1 {joint-iso-ccitt ms(9)
cmip(1) modules(0) protocol(3)};
trMObjectClass OBJECT IDENTIFIER ::= { tbd }
-- T1M1 has not defined actual OID
trAttribute OBJECT IDENTIFIER ::= { tbd }
-- T1M1 has not defined actual OID
trNotification OBJECT IDENTIFIER ::= { tbd }
-- T1M1 has not defined actual OID
CancelRequestedByManager ::= BOOLEAN
ManagedObjectInstance ::= ObjectInstance
PerceivedTroubleSeverity ::= INTEGER {
outOfService(0),
backInService(1),
Newnan Page 34
Draft ISO/CCITT GDMO MIBs to Internet MIBs 10/9/1992
serviceAffectingTrouble(2),
nonServiceAffectingTrouble(3)
}
PremisesAddress ::= PrintableString(SIZE(128))
PremisesName ::= PrintableString(SIZE(64))
ReceivedTime ::= GeneralizedTime
ServiceLocationList ::= SET OF SEQUENCE{
PremisesName,
PremisesAddress
}
TroubleFound ::= CHOICE{
number INTEGER {
pending(0),
cameClear(1),
centralOffice(2),
customerPremisesEquipment(3),
facility(4),
interexchangeCarrier(5),
information(6),
nonplanClassified(7),
noTroubleFound(8),
station(9),
servingBureau(10),
testOK(11),
publicServicesCoinSet(12),
otherStationEquipment(13),
stationWiring(14),
centralOfficeFacility(15),
customerOperatingInstructions(16),
testedOKVerifiedOK(17),
coFacilityTestedFoundOK(18),
outsideFacilityTestedFoundOK(19),
referredOutToOtherDept(20),
protectiveConnectingArrang(21),
cpeCustomerResponsibility(22)
},
identifier OBJECT IDENTIFIER
}
troubleReportCancelRequestedByManagerDefault BOOLEAN ::=
FALSE
-- Supporting Productions
TroubleAdministrationFunctionalUnits ::= BIT STRING
{
fm-ta-kernel (0),
fm-ta-req-trb-rpt-format (1),
fm-ta-trb-hist-evt- notif (2),
fm-ta-rev-trb-hist-recd (3),
fm-ta-add-trb-info (4),
fm-ta-trb-rpt-up-notif (5),
fm-ta-enrol-deenrol-notif (6),
fm-ta-ver-trb-rep-comp (7),
fm-ta-mod-trb-adm-info (8)
Newnan Page 35
Draft ISO/CCITT GDMO MIBs to Internet MIBs 10/9/1992
}
TroubleHistoryInfo ::= SEQUENCE{
managedObjectInstance [0] ObjectInstance,
receivedTime [1] GeneralizedTime,
troubleFound [2] TroubleFound,
additionalTroubleInfo [3] AdditionalTroubleInfo
OPTIONAL,
cancelRequestedByManager [4] CancelRequestedByManager
OPTIONAL,
closeOutNarr [5] PrintableString OPTIONAL,
closeoutVerification [6] CloseoutVerification
OPTIONAL,
commitmentTime [7] CommitmentTime OPTIONAL,
custTroubleTicketNumber [8] PrintableString
OPTIONAL,
perceivedTroubleSeverity [9] PerceivedTroubleSeverity
OPTIONAL,
restoredTime [10] GeneralizedTime OPTIONAL,
troubleReportNumberList [11] TroubleReportNumberList
OPTIONAL,
troubleType [12] TroubleType OPTIONAL
}
END
A.2 Output Internet MIB Macros
T1MODULE DEFINITIONS ::= BEGIN
IMPORTS OBJECT-TYPE, Counter FROM RFC1155-SMI;
t1TATroubleReportTable OBJECT-TYPE
-- class table
SYNTAX SEQUENCE OF T1TATroubleReportTableEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"t1TATroubleReport class table."
REFERENCE "trMObjectClass 5"
::= { t1TA 5 }
t1TATroubleReportTableEntry OBJECT-TYPE
-- class (table) entry
SYNTAX T1TATroubleReportTableEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"t1TATroubleReportTable instance"
INDEX { t1TATroubleReportIndex }
::= { t1TATroubleReportTable 1 }
T1TATroubleReportTableEntry ::= SEQUENCE {
Newnan Page 36
Draft ISO/CCITT GDMO MIBs to Internet MIBs 10/9/1992
t1TATroubleReportDelete
INTEGER,
t1TATroubleReportIndex
INTEGER,
t1TATroubleReportCancelRequestedByManager
INTEGER,
t1TATroubleReportManagedObjectInstance
OBJECT IDENTIFIER,
t1TATroubleReportReceivedTime
DisplayString,
t1TATroubleReportTroubleFoundNumber
INTEGER,
t1TATroubleReportTroubleFoundIdentifier
OBJECT IDENTIFIER,
t1TATroubleReportPerceivedTroubleSeverity
INTEGER
}
t1TATroubleReportDelete OBJECT-TYPE
-- class entry delete indicator
SYNTAX INTEGER
ACCESS write-only
STATUS mandatory
DESCRIPTION
"When set to zero, the corresponding entry of the
t1TATroubleReportTable is deleted."
::= { t1TATroubleReportTableEntry 1 }
t1TATroubleReportIndex OBJECT-TYPE
-- class entry index
SYNTAX INTEGER
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"Distinguishes unique entries of
t1TATroubleReportTable"
::= { t1TATroubleReportTableEntry 2 }
-- Consistent with the current ANSI GNM, there are no
-- attributes associated with TOP.
-- there is one level of derivation for TroubleReport, arc
-- numbering commences at 2+10= 12 rounded up to the
-- nearest multiple of ten, i.e., with arc number 20:
t1TATroubleReportCancelRequestedByManager OBJECT-TYPE
-- class table concepual column
SYNTAX INTEGER
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The Cancel Requested By Manager attribute
indicates whether the manager has initiated the
process to cancel a Trouble Report."
REFERENCE "trAttribute 12"
Newnan Page 37
Draft ISO/CCITT GDMO MIBs to Internet MIBs 10/9/1992
-- the following corresponds to a DEFAULT
-- VALUE OF
--troubleReportCancelRequestedByManagerDefault
-- BOOLEAN ::= FALSE DEFVAL { 0 }
::= { t1TATroubleReportTableEntry 20 }
t1TATroubleReportManagedObjectInstance OBJECT-TYPE
-- recall that ObjectInstance maps to class entry instance
SYNTAX OBJECT IDENTIFIER
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The Managed Object Instance attribute indicates
the CNM Service object class instance or the GNM
telecommunications network resource instance
associated with a particular trouble report
instance."
REFERENCE "trAttribute 29"
::= { t1TATroubleReportTableEntry 21 }
t1TATroubleReportReceivedTime OBJECT-TYPE
SYNTAX DisplayString
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The Received Time attribute indicates the date
and time when a trouble report was entered."
REFERENCE "trAttribute 33"
::= { t1TATroubleReportTableEntry 22 }
-- Note that t1TATroubleReportAccessTimeLocationList is not
-- assigned arc 23 because it is implemented as a side table
-- due to its multivalued, complex syntax; see below.
-- Exactly one of the following two choices will be present
-- for a given table entry. These are enumerated in-line (in
-- the class table) rather than in a side table because the
-- syntax cannot be multi-valued.
t1TATroubleReportTroubleFoundNumber OBJECT-TYPE
SYNTAX INTEGER {
pending(32767),-- value of zero not permitted
cameClear(1),
centralOffice(2),
customerPremisesEquipment(3),
facility(4),
interexchangeCarrier(5),
information(6),
nonplanClassified(7),
noTroubleFound(8),
station(9),
servingBureau(10),
testOK(11),
Newnan Page 38
Draft ISO/CCITT GDMO MIBs to Internet MIBs 10/9/1992
publicServicesCoinSet(12),
otherStationEquipment(13),
stationWiring(14),
centralOfficeFacility(15),
customerOperatingInstructions(16),
testedOKVerifiedOK(17),
coFacilityTestedFoundOK(18),
outsideFacilityTestedFoundOK(19),
referredOutToOtherDept(20),
protectiveConnectingArrang(21),
cpeCustomerResponsibility(22)
}
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The Trouble Found attribute specifies an
enumerated code value, which identifies the
problem resolved. This field will be copied into
the trouble history information."
REFERENCE "trAttribute 45"
::= { t1TATroubleReportTableEntry 23 }
t1TATroubleReportTroubleFoundIdentifier OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The Trouble Found attribute specifies an
enumerated code value, which identifies the
problem resolved. This field willbe copied into
the trouble history information."
REFERENCE "trAttribute 45"
::= { t1TATroubleReportTableEntry 24 }
t1TATroubleReportPerceivedTroubleSeverity OBJECT-TYPE
SYNTAX INTEGER {
outOfService(32767),
backInService(1),
serviceAffectingTrouble(2),
nonServiceAffectingTrouble(3)
}
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The Perceived Trouble Severity attribute allows
the manager to indicate the effect of the trouble
on the managed object being reported"
REFERENCE "trAttribute 32"
::= { t1TATroubleReportTableEntry 25 }
-- the following is a side table because it is translated
-- from a multi-valued attribute:
t1TATroubleReportAccessTimeLocationListTable OBJECT-TYPE
Newnan Page 39
Draft ISO/CCITT GDMO MIBs to Internet MIBs 10/9/1992
-- side table
SYNTAX SEQUENCE OF
T1TATroubleReportAccessTimeLocationListTableEntry
ACCESS not-accessible
STATUS mandatory
-- this attribute is in a conditional package
-- thus the table may be empty
DESCRIPTION
"The Access Time Location list attribute
identifies the set or subset of service locations
for which the Location Access Hours attribute
values are valid."
REFERENCE "trAttribute 2"
::= { t1TATroubleReport 2 }
t1TATroubleReportAccessTimeLocationListTableEntry OBJECT-TYPE
-- side table entry
SYNTAX T1TATroubleReportAccessTimeLocationListTableEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"t1TATroubleReportAccessTimeLocationListTable entry."
INDEX {
t1TATroubleReportAccessTimeLocationListClassIndex,
t1TATroubleReportAccessTimeLocationListValueIndex
}
::= { t1TATroubleReportAccessTimeLocationListTable 1 }
T1TATroubleReportAccessTimeLocationListTableEntry
::= SEQUENCE {
t1TATroubleReportAccessTimeLocationListDelete
INTEGER,
t1TATroubleReportAccessTimeLocationListClassIndex
INTEGER,
t1TATroubleReportAccessTimeLocationListValueIndex
INTEGER,
t1TATroubleReportAccessTimeLocationListPremisesName
DisplayString,
t1TATroubleReportAccessTimeLocationListPremisesAddress
DisplayString
}
t1TATroubleReportAccessTimeLocationListDelete OBJECT-TYPE
-- side table delete indication
SYNTAX INTEGER
ACCESS write-only
STATUS mandatory
DESCRIPTION
Newnan Page 40
Draft ISO/CCITT GDMO MIBs to Internet MIBs 10/9/1992
"When set to zero, the corresponding entry of the
access time location list table is deleted."
::= { t1TATroubleReportAccessTimeLocationListTableEntry 1 }
t1TATroubleReportAccessTimeLocationListClassIndex OBJECT-TYPE
-- side table class index
SYNTAX INTEGER
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"Has same value as class entry index of managed
object."
::= { t1TATroubleReportAccessTimeLocationListTableEntry 2 }
t1TATroubleReportAccessTimeLocationListValueIndex OBJECT-TYPE
-- side table value index
SYNTAX INTEGER
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"Uniquely discriminates a value of
t1TATroubleReportAccessTimeLocationList within a
managed object"
::= { t1TATroubleReportAccessTimeLocationListTableEntry 3 }
t1TATroubleReportAccessTimeLocationListPremisesName
OBJECT-TYPE
SYNTAX DisplayString
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The access time for a service location list
premises name."
::= { t1TATroubleReportAccessTimeLocationListTableEntry 20 }
t1TATroubleReportAccessTimeLocationListPremisesAddress OBJECT-
TYPE
SYNTAX DisplayString
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The access time for a service location
listpremises address."
::= { t1TATroubleReportAccessTimeLocationListTableEntry 21 }
END
Appendix B Abridged ISO/CCITT Compatibility MIB
ISOCCITTCOMPATIBILITY DEFINITIONS ::= BEGIN
IMPORTS OBJECT-TYPE, Counter FROM RFC1155-SMI;
Newnan Page 41
Draft ISO/CCITT GDMO MIBs to Internet MIBs 10/9/1992
-- Following is an abridged ISO/CCITT Compatibility MIB.
-- The purpose of the ISO/CCITT compatibility MIB is to
-- facilitate ISO/CCITT GDMO to Internet MIB translation.
-- It has two primary features:
-- Parent and child tables that navigation of containment
-- relationships.
-- Mapping of common notifications to traps.
-- The following should be self-explanatory with sufficient
-- comments added:
ocNextLocallyUniqueIndex OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Provides a unique integer sub-identifier for
purposes of manager-initiated creation
of rows in tables (i.e., new managed object
instances or new values for multi-valued
attributes). Successive reads to this object
return different values that are unique
within the scope of the agent. Such values may be
assigned arbitrarily by the agent
so a manager should make no assumption about the
sequence or magnitude of values which
will be returned. "
::= { ocObjectCreation 1 }
ocNextGloballyUniqueIndex OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Like ocNextLocallyUniqueIndex, provides a unique
integer sub-identifier for purposes
of manager-initiated object creation. However,
the number assigned is guaranteed to
be unique within a (private) administrative
domain, permitting creation of objects
that are visible across multiple Internet agents
in that domain."
::= { ocObjectCreation 2 }
-- Following is the parent table; given the SNMP-DN of an
-- object, it yields the SNMP-DN for that
-- object's parent (immediately containing) object.
ocParentTable OBJECT-TYPE
SYNTAX SEQUENCE OF OcParentTableEntry
ACCESS not-accessible
STATUS mandatory
Newnan Page 42
Draft ISO/CCITT GDMO MIBs to Internet MIBs 10/9/1992
DESCRIPTION
"Allows parents in the ISO/CCITT Management naming
hierarchy to be determined.
INDEX is OBJECT IDENTIFIER, i.e., SNMP
Distinguished Name."
::= { ocObjectCreation 3 }
ocParentTableEntry OBJECT-TYPE
SYNTAX OcParentTableEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"Entry of parent table."
INDEX { ocParent }
::= { ocParentTable 1 }
OcParentTableEntry ::=
SEQUENCE { ocParent OBJECT IDENTIFIER }
ocParent OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
ACCESS read-write
STATUS mandatory
DESCRIPTION
"Provides the SNMP Distinguished Name of the
parent. An manager can only set
this value when creating a new instance of a
managed object class, and
only for those object classes for which manager-
initiated instance creation
is allowed."
::= { ocParentTableEntry 1 }
-- Following is the child table; given the SNMP-DN of an
-- object, it yields a list of SNMP-DNs
-- for objects immediately subordinate to that object.
ocChildTable OBJECT-TYPE
SYNTAX SEQUENCE OF OcChildTableEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"Allows children in the ISO/CCITT Management
naming hierearchy to be determined."
::= { ocObjectCreation 4 }
ocChildTableEntry OBJECT-TYPE
SYNTAX OcChildTableEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"Entry of Child table."
INDEX { ocParentOfChild, ocChild }
::= { ocChildTable 1 }
Newnan Page 43
Draft ISO/CCITT GDMO MIBs to Internet MIBs 10/9/1992
OcChildTableEntry ::= SEQUENCE {
ocParentOfChild OBJECT IDENTIFIER,
ocChild INTEGER
}
ocParentOfChild OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Provides the SNMP-DN of the parent."
::= { ocChildTableEntry 1 }
ocChild OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This parameter is typically used in conjunction
with a get next operation to acquire SNMP-DNs for
successive child (contained) objects, given the
parent. If this value is zero, the first child in
the list is returned. If it is a class prefix,
the first child in the given class is returned.
If it is the full SNMP-DN, the SNMP-DN of the next
higher child is returned. "
::= {ocChildTableEntry 2}
-- Following is the NAME BINDING table. It allows the NAME
-- BINDING OBJECT IDENTIFIER of an object instance to be
-- gotten or set (can be set only on object creation).
ocNameBindingTable OBJECT TYPE
SYNTAX SEQUENCE OF OcNameBindingTableEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"Allows the NAME BINDING registration to be
specified on object creation, or
fetched for an existing class entry instance.."
::= { ocObjectCreation 4 }
ocNameBindingTableEntry OBJECT TYPE
SYNTAX OcNameBindingTableEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"Entry of name binding table."
INDEX { OBJECT IDENTIFIER } -- class entry instance
::= { ocParentTable 1 }
OcParentTableEntry ::= SEQUENCE
{ ocNameBindingRegistry OBJECT IDENTIFIER }
Newnan Page 44
Draft ISO/CCITT GDMO MIBs to Internet MIBs 10/9/1992
ocNameBindingRegistry OBJECT TYPE
SYNTAX OBJECT IDENTIFIER
ACCESS read-write
STATUS mandatory
DESCRIPTION
"Provides the Name binding registration on object
creation and can also be fetched. A manager can
only set this value when creating a new instance
of a managed object class, and only for those
object classes for which manager-initiated
instance creation is allowed."
::= { ocNameBindingTableEntry 1 }
-- A limited mapping of notifications to traps is provided
-- using the objects defined below. These should be
-- registered in a subtree administered by some neutral
-- organization, if not in subtrees administered by the
-- originating organization which owns the base standard
-- being translated. This is an abridged set which continues
-- the TroubleReport example.
-- The following traps correspond to joint ISO-CCITT
-- notifications, i.e.,as defined in ISO 10165-2. Integers
-- in the range of 1-100 are reserved for traps corresponding
-- to such notifications. These should be defined in
-- a subtree administered by some neutral organization, if
-- not in subtrees administered by the originating
-- organization
onObjectCreation TRAP-TYPE
ENTERPRISE neutralForum
VARIABLES { onReportedInstance }
DESCRIPTION "Per ISO IS 10165-2"
REFERENCE "ISO 10165-2 smi2Notification 6"
::= 6
onObjectDeletion TRAP-TYPE
ENTERPRISE neutralForum
VARIABLES { onReportedInstance }
DESCRIPTION "Per ISO IS 10165-2"
REFERENCE "ISO 10165-2 smi2Notification 7"
::= 7
-- ISO Only Series, range 100-199
-- CCITT Only Series, range 200-299
-- ANSI Committee T1 Series, range 300-399
onTroubleHistoryEventNotification TRAP-TYPE
ENTERPRISE neutralForum
VARIABLES {
Newnan Page 45
Draft ISO/CCITT GDMO MIBs to Internet MIBs 10/9/1992
onReportedInstance,
onReceivedTime,
-- exactly one of the following two
-- is meaningful for a particular
-- onTroubleHistoryEventNotification trap:
onTroubleFoundNumber,
onTroubleFoundIdentifier
}
DESCRIPTION "Per ANSI GNMTA."
::= 300
-- The following objects are not accessible and exist only
-- for purposes of specifying variables for traps. With the
-- exception of reportedInstance, they correspond to
-- ISO/CCITT notification parameters of the same name which
-- are mandatory for one of more of the notification types
-- mentioned above.
-- In all cases, the reportedInstance object is used to
-- identify the SNMP Distinguished Name corresponding to the
-- ISO/CCITT managed object instance and Internet class table
-- entry for which an event is being reported.
onReportedInstance OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"Reports the SNMP Distinguished Name for which a
notification trap is being reported."
::= {onObjectNotification 100}
onProbableCause OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"Per ISO 10165-2. Value assignments for probable
cause are as specified in Attribute-ASN1Module
{joint-iso-ccitt ms(9) smi(3)
part2(2) asn1Module(2) 1}"
REFERENCE "ISO 10165-2 smi2AttributeID 53"
::= {onObjectNotification 101}
onReceivedTime OBJECT-TYPE
SYNTAX OCTET STRING -- GeneralizedTime
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"As described in ANSI GNMTA"
REFERENCE "ANSI GNMTA trAttribute 33"
::= {onObjectNotification 102}
onTroubleFoundNumber OBJECT-TYPE
Newnan Page 46
Draft ISO/CCITT GDMO MIBs to Internet MIBs 10/9/1992
SYNTAX INTEGER -- (enumerated)
-- value of zero indicates OID being used instead
-- pending(32767),
-- cameClear(1),
-- centralOffice(2),
-- customerPremisesEquipment(3),
-- facility(4),
-- interexchangeCarrier(5),
-- information(6),
-- nonplanClassified(7),
-- noTroubleFound(8),
-- station(9),
-- servingBureau(10),
-- testOK(11),
-- publicServicesCoinSet(12),
-- otherStationEquipment(13),
-- stationWiring(14),
-- centralOfficeFacility(15),
-- customerOperatingInstructions(16),
-- testedOKVerifiedOK(17),
-- coFacilityTestedFoundOK(18),
-- outsideFacilityTestedFoundOK(19),
-- referredOutToOtherDept(20),
-- protectiveConnectingArrang(21),
-- cpeCustomerResponsibility(22)
-- OBJECT IDENTIFIER choice not supported
-- in Internet MIB translation
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"As described in ANSI GNMTA"
REFERENCE "ANSI GNMTA trAttribute 45"
::= {onObjectNotification 103}
onTroubleFoundIdentifier OBJECT-TYPE
-- empty object id indicates INTEGER choice being used
SYNTAX OBJECT IDENTIFIER
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"As described in ANSI GNMTA"
REFERENCE "ANSI GNMTA trAttribute 45"
::= {onObjectNotification 104}
neutralForum OBJECT IDENTIFIER ::= { experimental 1 }
END
- INTERNET DRAFT Expires April 23, 1993 -
Newnan Page 47